Languguage OS 2/Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO/language/pcpil/pidoc8.txt

Text File | 1994-02-28 | 36KB | 787 lines

ASCII CHARACTERS 128 TO 255

INPUT CHARACTERS IN PILOT

The ACCEPT statement allows codes 32 to 255 to be entered as part of student
replies.  Characters in this range are echoed to the display so that the
student sees what has been typed.

Characters from 0 to 31 are reserved for special purposes; specifically,
character 13 is the RETURN character which signals the end of the student
reply.  Character 8 is a backspace character which may be used to back up and
correct typing errors. And character 3 (ctrl-C) cancels a PILOT program
immediately. Other characters in the range 0 to 31 are completely ignored by
the ACCEPT statement (unless it is an ACCEPT-SINGLE, AS: in which case all
codes other than ctrl-C may be entered).

BASIC appendix G, pages G2 and G3, show the codes generated for most of the
normal printable character keys on the keyboard. The chart below shows the
codes generated for the various special keys on the keyboard.

DEFAULT KEYBOARD CODES ON AN ACCEPT STATEMENT

128-131     alt- 9 0 - =
132         ctrl-pg up
143         shift-tab
144-153     alt- Q W E R T Y U I O P
158-166     alt- A S D F G H J K L
172-178     alt- Z X C V B N M
187-196     f1 f2 f3 f4 f5 f6 f7 f8 f9 f10
199         home
200         cursor up
201         pg up
203         cursor left
205         cursor right
207         end
208         cursor down
209         pg dn
210         ins
211         del
212-221     shift- f1 f2 f3 f4 f5 f6 f7 f8 f9 f10
222-231     ctrl-  f1 f2 f3 f4 f5 f6 f7 f8 f9 f10
232-241     alt- f1 f2 f3 f4 f5 f6 f7 f8 f9 f10
242         ctrl-prtsc
243         ctrl-cursor left
244         ctrl-cursor right
245         ctrl-end
246         ctrl-pg dn
247         ctrl-home
248-255     alt- 1 2 3 4 5 6 7 8

HOW TO CHANGE KEYBOARD VALUES

The  NX: statement allows the program to  change the  code  generated by any
key from  the  value shown  in the above table (or in BASIC  appendix G)  to
any other value from 0 to 255.  In  this manner the student can be informed
regarding  an alternate use of the keys when responding.  Thus the following
statements would make sense.

       NX:153,227
       T: Dear student,
       :  If you wish to reply with the Greek letter
       :  PI in any of your answers hold down the
       :  ALT key while pushing the P key.

After the above NX: statement, any time the student typed ALT-P, character
227 would be entered into the answer buffer and (assuming screen mode 0-3)
the letter PI would appear on the  screen. The ability to re-define the
keyboard keys allows the student to answer  with any  characters the program
writer has chosen. The AX:  op code can be used to make the keys temporarily
act like their normal defaults when it is necessary to be able to use the
keyboard in two ways depending on the context.

192 @      224 `
193 A      225 a
194 B      226 b
195 C      227 c
196 D      228 d
197 E      229 e
198 F      230 f
199 G      231 g
200 H      232 h
201 I      233 i
202 J      234 j
203 K      235 k
204 L      236 l
205 M      237 m
206 N      238 n
207 O      239 o
208 P      240 p
209 Q      241 q
210 R      242 r
211 S      243 s
212 T      244 t
213 U      245 u
214 V      246 v
215 W      247 w
216 X      248 x
217 Y      249 y
218 Z      250 z
219 [      251 {
220 \      252 |
221 ]      253 }
222 ^      254 ~
223 _      255 Alt-8



Appendix C. STUDENT RECORDS

The File In, File Out and Keep statements can be used in many combinations to
perform custom student record keeping. The unique needs of any program can be
accommodated by programming the desired record keeping functions into the
program. There are however, several typical record keeping functions that may
occur in substantially the same form over and over. Since these needs arise
repeatedly PILOT provides a set of simple macros which can be used to include
student record keeping in a program with minimal effort.

To use these macros, the author would include them at the appropriate points
in the program via the F7 key of the EZ editor.

RESTART MACROS

The term "restart" implies that the student may leave the program prior to
completion, and may resume at the same point in the program at a later time.
These macros are used to build a student restart file which contains the
student's id number, name, and the point at which the student should resume
upon return to the program. These macros also provide for the preservation of
data about the student's progress.  The size and nature of that data is up to
the programmer.

To use these two macros it is necessary to include the "RESTART.PIM" macro in
the initialization section of the program. Then the "CHECKPT.PIM" macro is
included at every point within the program where the student might be
permitted to resume upon return. If the program is a series of distinct
problems, the start of each problem might be considered to be a check point.


PROGRAM ORGANIZATION

The organization of the program should be as follows:

       <your program initialization code>

       RESTART macro expanded here
       . . .

       CHECKPT macro expanded here
       <first section of the program>

       CHECKPT macro expanded here
       <second section of the program>

       CHECKPT macro expanded here
       <third section of the program>
       . . .

       CHECKPT macro expanded here
       <message informing user that program is completed>


THE  RESTART.PIM  MACRO

Prior to the RESTART macro, use EZ to write your dimension statements, set
the screen modes, etc, and perform any initial code which would need to be
done for any student whether returning to the program or starting for the
first time.

Then, still in EZ, position after the above statements, push F7 and enter the
name RESTART.PIM.  The RESTART macro prompts for two parameters. The first is
the name of the file to be used for keeping student data. You can enter any
valid file name or just push the ENTER key to use the default file name
"RESTART".

The second prompt requests the size of the user data area to be set aside in
each student record. This area is used to store any data your program might
need to keep about a student. The restart macro records this data at each
check point and restores it upon each program restart. The programmer can
choose to retain from 0 to 500 bytes of student data. In the simplest case
just push ENTER to indicate that no optional student data area is needed.

Once the two parameters are entered the RESTART macro expands about 3 screens
of PILOT code. When the program is executed, the code asks for the student
ID, and name. It maintains the restart file and handles the branching of the
student to the appropriate restart point upon return.

THE  CHECKPT.PIM  MACRO

Next, determine which points within the program are check points. A student
always resumes at the last check point passed prior to leaving the program.
At the start of each section which is to be a check point, use the F7 key and
enter the name CHECKPT.PIM.  This macro expands the code necessary to save
the student restart data at that point so that restart can function.

It is completely up to the programmer to determine how many check points are
placed in the program, and where they are placed. Each time the student
reaches a check point the location of the check point and the current value
of the user data variable UDAT$ is recorded in the restart file under that
student's id. When a student starts the program, the student's id number is
used to look up the student record. The value of the user data variable UDAT$
is restored from the last data saved in the student record, then a Jump is
performed to the last check point location saved for that student.


SAVING USER DATA

The program can use the restart facility to save data about the student from
one run to the next. To do so, when entering the RESTART macro, indicate the
number of bytes to be reserved in each student record for optional data. The
number may be from 1 to 500. The actual amount is up to the programmer. This
data is saved and restored by the restart facility but its actual use in the
program is determined only by how the programmer uses the data.

The restart macro creates a string variable called UDAT$ which has a maximum
length equal to the size specified for optional user data. Each call to the
CHECKPT macro causes the current contents of UDAT$ to be recorded in the
student's record on disk. When a student returns to the program the last
value saved for UDAT$ is restored to the variable UDAT$ prior to jumping to
the instruction just after the CHECKPT.

The program can place any data within the string UDAT$ prior to each call to
CHECKPT. And, if necessary the data can be moved from UDAT$ to other
variables just after each call to CHECKPT.

THE RESTART FILE

The student record file is in ascii text format and contains one line per
student. Each line contains a 10 byte field for student id number, a 30 byte
field for name, a 10 byte field for the last check point label, from 1 to 500
bytes of optional user data, a return character and a line feed character. To
list the file on the display enter the command:

     TYPE  RESTART

To print the student record file enter the command:

     COPY  RESTART  PRN:


Appendix D. GRAPHIC IMAGE PROCESSING

The PILOT GX: command can be used to display a graphic image stored in a disk
file. The GX: command accepts an image in BSAVE format, so called because it
is the format that is produced by the BASIC language BSAVE command. There are
some limitations to this format and the GX: command. First, only the original
CGA modes, 0 through 6 are supported, not the higher resolution modes of the
EGA. Second, the pictures are stored as uncompressed bit mapped images, so
each picture occupies 16K on disk regardless of the complexity of the
picture. Third, the GX: command always displays the entire picture, and does
not use any special effects in the display.

PILOT includes a set of utilities to address these limitations. These
utilities permit the author to:

     Import a picture created by a graphics programs for
     display from within a PILOT lesson.

     Store the picture on disk in a compressed format which
     reduces the storage requirements.

     Display a picture in any graphics mode, including the
     EGA high resolution modes.

     Display an entire picture, or any portion of the picture.
     When a portion of a picture is displayed, it may be
     positioned anywhere on the display.

     Display the picture using a variety of special effects,
     such as horizontal and vertical wipes or fades.

The user must distinguish between pictures which will be displayed in low
resolution modes (4, 5 and 6) and those which will be displayed in EGA modes
(13, 14 and 16). For the low resolution modes, pictures are 320 by 200
pixels, 4 colors.  PILOT programs expect these pictures to be in PIQ format.
A picture to be used in a low resolution mode can be created with the GIE
program which is included with PILOT, via a PILOT program which saves the
picture via the GSX: statement, or by capturing the image from another
program with the BSAVER utility. These image files can be compressed and
stored in PIQ format via the PIQCMPRS utility. PIQCMPRS can also be used to
convert a .PCX file created via PC/Paintbrush to PIQ format.  Then the images
may be displayed in a PILOT program via the PIQI, PIQS and PIQF macros.

For EGA high resolution modes, pictures can be up to 640 by 350, 16 colors.
PILOT programs expect these pictures to be in PCX format as produced by
PC/Paintbrush (trademark of Zsoft Corporation). These pictures can be created
with PC/Paintbrush (installed for EGA mode), or by using the FRIEZE utility
program (part of Paintbrush) to capture a screen image from another program.
Since this format is already in a compressed form, PILOT does not require any
further processing of the picture, it can be called up from a PILOT program
in exactly the form created by Paintbrush. These images can be displayed in a
PILOT program via the EGAPIQI and EGAPIQ macros.

The various utilities for managing graphic images of both
types are described below.

LOW RESOLUTION PICTURES

Low resolution pictures can be used on an IBM Color Graphics Adapter (CGA) or
Extended Graphics Adapter (EGA). These pictures are displayed in PILOT screen
modes 4, 5 or 6. To use a picture of this form in your PILOT program follow
these steps:

     Create the picture with GIE, or via a PILOT program GSX:
     command, or with PC/Paintbrush (installed for 320 by 200
     mode), or via the BSAVER capture utility.

     Run the PIQCMPRS utility to convert and compress the
     picture to PIQ format.

     Use the EZ editor to expand the PIQI, PIQF and/or PIQS
     macros into your PILOT program.

The BSAVER Utility

The file BSAVER.EXE contains the BSAVER utility. It can be used to capture a
graphic image from any program which operates in 320 by 200 screen mode (CGA
graphics mode). To use BSAVER you first load it into RAM via the command

     BSAVER

This does not cause anything visible to happen. Rather, BSAVER loads into
memory and remains there until called up later.

Having loaded BSAVER, execute the graphics program with which you will create
the picture. Run it normally until the picture you wish to capture is
displayed.

Then push the PRTSC key (while holding down SHIFT). BSAVER wakes up and
displays a prompt on the top of the screen. The prompt shows the file name
BSAVER will use to save the current screen display. You can continue by
pressing Enter, or you can type another file name to use. BSAVER increments
the file name so that it is convenient to use it to capture a series of
pictures without entering a new file name for each.

The files created by BSAVER are in BSAVE format. These files can be processed
by GIE, by the PILOT GX: command, or by the PIQCMPRS utility.

If the image captured by BSAVER is a text mode image, it can be used directly
in a PILOT program by setting the appropriate screen mode, and referring to
the file via the GX: command.  Though the same method would work for a
graphics mode image, it is reccommended that the image be converted first to
PIQ format.  This saves space and enhances the possible display options.

The PIQCMPRS Utility

This utility is used to convert a BSAVE or PCX format picture to PIQ format.
It is valid for CGA graphics modes only, 320 by 200, 4 color. To use it enter
the command:

     PI PIQCMPRS

Then follow the prompt to enter the name of the input file. If the input file
name ends in ".PCX", it is assumed to be in PC/Paintbrush format. Otherwise
it is assumed to be in BSAVE format. The graphic image is then saved in a
file with a suffix of ".PIQ".

The PIQI, PIQS, PIQF and GETFILE Macros

These macros can be included in your PILOT program to display pictures which
have been prepared via the PIQCMPRS utility. The EZ editor is used to expand
these macro calls in your program. To expand a macro, move the cursor to the
desired position in the program file and push the F7 function key. Then enter
the macro name (complete with the .PIM suffix). Then respond to each prompt
as necessary. The use of each macro is detailed below.

PIQI.PIM

The PIQI macro must be expanded toward the start of the program. It reads in
the binary file PIQSHOW.BIN and prepares for display of PIQ images. PIQI need
only be executed once per program. The file PIQSHOW.BIN must be present with
the program when it is executed. The macro files need only be present when
the program is written.

PIQF.PIM

Once the PIQI macro has been executed once, any number of PIQF macros can be
used. The PIQF macro causes the display of a picture, stored in a PIQ file.
To use PIQF push the F7 function key in EZ, and enter the name PIQF.PIM. The
following parameters must be entered in response to the PIQF prompts:

     Filename

Here enter the name of the image file. Though the file name is of the form
nnn.PIQ, do not enter the ".PIQ" suffix. Just enter the first part of the
file name.

     Wipe (C, D, E, F, H, I, L, R, U, V)

This selects the manner in which the image is painted onto the screen. One of
the following letters must be entered :

     C is from upper left corner.
     D is down, from top to bottom.
     E is explode from center out.
     F is a fade in.
     H is a horizontal spilt towards both edges.
     I  is implode from edges inward.
     L is from right to left.
     R is from left to right.
     U is up from bottom to top.
     V is vertical spilt from center to top and bottom.

     Option: Xor Mode or Border Color

This prompt permits input of additional wipe information. It may be used to
specify the XOR option on any wipe except the fade. The xor option causes the
image to be blended with the existing display rather than to overlay it. A
second possibility for this prompt is to specify a number 0, 1, 2 or 3 for
the down or right wipes. The number indicates that a border is to precede the
down or rightward wipe. The number indicates the color of the border. If
neither the xor or border option is desired, this reply may be left blank.

     Change Window Parameters

This prompt requests a y (for yes) or n (for no) response. In fact, any
response except y is taken as a no. The window parameters determine whether
the entire picture, or just part of the picture is to be displayed. A no
response indicates that the last window parameters executed on any PIQF or
PIQS macro are to be used again. The default setting when the program begins
causes the entire image to be displayed. A yes response causes four
additional prompts for the window boundaries: leftmost column (0-39),
rightmost column (0-39), top row (0-24) and bottom row (0-24).

     Change Position Parameters

This prompt requests a y or n response. The position parameters can be used
when a partial image is displayed to place the partial image at any screen
location. A no response indicates that the last position parameters executed
on any PIQF or PIQS macro are to be used again. A yes response causes two
additional prompts for the new position: leftmost column (0-39) and top row
(0-24).

     Delay Time (0-254)

This parameter controls the speed at which the special effect is performed. 0
indicates maximum speed, which with a D wipe is the fastest display possible.
As the delay time is increased, the speed is decreased.

PIQS.PIM

PIQS, like PIQF, is used to display a PIQ image. PIQF is used to read the
image from a file, then display it. PIQS is used to display an image which
has previously been read into a string variable. PIQS is useful when one
image is to be displayed repeatedly since it can avoid the overhead of re-
reading the image from disk. It can also be used when several images are to
be displayed in rapid succession since all the images could be pre-read from
disk prior to the display of the first image. To use PIQS the program must
first have loaded the image file into a string variable via the GETFILE
macro. The prompts for PIQS are similar to those for PIQF except that rather
than entering the name of a file containing the image, the author must enter
the name of a string variable containing the image.

GETFILE.PIM

The GETFILE macro can be used to create a string variable and read the
contents of a disk file into the string variable. It can be used to read in a
PIQ image, a sprite table, a binary subroutine, or other data. Its use in
conjunction with PIQ images is to pre-load a picture prior to using the PIQS
macro.

The PIQ Binary Files

There are several binary files associated with PIQ image processing. Each is
of the form "PIQnnn.BIN". The only file which needs to be distributed with
the final PILOT program is PIQSHOW.BIN. The other binary files, as well as
the PIQ macro files need be present only when writing the program.


HIGH RESOLUTION PICTURES

High resolution pictures can be used only on an IBM Extended Graphics Adapter
(EGA), not on a Color Graphics Adapter (CGA). This facility can be used to
display pictures in PILOT screen modes 13, 14 and 16. To display a picture it
must be created via PC/Paintbrush using the corresponding screen mode. To use
a picture of this form in your PILOT program follow these steps:

     Use PC/Paintbrush (installed for an EGA color mode) to
     draw a picture. Save it in the normal manner. Or, use the
     FRIEZE utility to capture an image from another program
     in an EGA mode.

     Use the EZ editor to expand the EGAPIQI and EGAPIQ
     macros into your PILOT program.

The EGAPIQI and EGAPIQ Macros

These macros can be included in your PILOT program to display pictures which
are in PCX format for EGA screen modes. The EZ editor is used to expand these
macro calls in your program. To expand a macro, move the cursor to the
desired position in the program file and push the F7 function key.  Then
enter the macro name (complete with the .PIM suffix).  Then respond to each
prompt as necessary.

EGAPIQI.PIM

The EGAPIQI macro must be expanded toward the start of the program. It reads
in the binary file EGAPIQ.BIN and prepares for display of EGAPIQ images.
EGAPIQI need only be executed once per program. The file EGAPIQ.BIN must be
present with the program when it is executed. The macro files need only be
present when the program is written.

EGAPIQ.PIM

The EGAPIQ macro may be used at any point in a program to display an EGA mode
picture. EGAPIQI must have been executed prior to EGAPIQ. To use EGAPIQ push
the F7 function key in EZ, and enter the name EGAPIQ.PIM. The following
parameters must be entered in response to the EGAPIQ prompts:

     Filename

Here enter the name of the image file. Though the file name is of the form
nnn.PCX, do not enter the ".PCX" suffix. Just enter the first part of the
file name.

     Wipe (D, F, L, R, U)

This selects the manner in which the image is painted onto the screen. One of
the following letters must be entered :

     D is down, from top to bottom.
     F is a fade in.
     L is from right to left.
     R is from left to right.
     U is up from bottom to top.

     Change Window Parameters

This prompt requires a y (for yes) or n (for no) response. In fact, any
response except y is taken as a no. The window parameters determine whether
the entire picture, or just part of the picture is to be displayed. A no
response indicates that the last window parameters executed on any EGAPIQ
macro are to be used again. The default setting when the program begins
causes the entire image to be displayed. A yes response causes four
additional prompts for the window boundaries: leftmost column (0-79),
rightmost column (0-79), top row (0-24) and bottom row (0-24).

     Change Position Parameters

This prompt requires a y or n response. The position parameters can be used
when a partial image is displayed to place the partial image at any screen
location. A no response indicates that the last position parameters executed
on any EGAPIQ macro are to be used again. A yes response causes two
additional prompts for the new position: leftmost column (0-79) and top row
(0-24).

     Delay Time (0-254)

This parameter controls the speed at which the special effect is performed. 0
indicates maximum speed, which with a D wipe is the fastest display possible.
As the delay time is increased, the speed is decreased.


Appendix E. LARGE COMPUTER SIMULATION

With PILOT, a simulation program can be created to provide effective operator
practice and training on the operation of a large scale computer system
operator's console. Such a simulation can be used as in inexpensive
substitute for the actual mainframe system for training purposes.

Program example SAMPLE12.PIL is an example, derived from an actual full scale
simulator, which shows how this type of program might be developed with
PILOT. The goal of a simulator is to provide the user with a simulated copy
of the target computer system that allows for practical hands-on training in
a controlled environment. Though this example simulates a mainframe computer
console, similar technics could be used to simulate other systems. Advantages
of simulation include the ability to train operators and users before a
machine is installed, or to train new personel without tying up the actual
system.

After a simulator is built, much of the same code might be used in a
companion tutorial program which, together with the simulator would make up a
complete training package.

One approach for simulation of hardware systems is to build a complete
simulator first, then build various tutorial modules to allow for task skills
to be practiced be entering the simulator at different points.   The entry
modules would thus set up the environment of the simulator for each new task
to be learned.  After that task is practiced the student could return to the
tutorial for more instruction.

Building the Simulator

Most mainframe systems accept command sequences that an operator uses to
configure, start, stop, initialize control programs, and control the hardware
of the machine from a console.  Each screen of control information is called
a 'frame'. When any particular frame is displayed, there are certain keyboard
actions that operator might perform. Some actions move to another frame,
others might invoke commands unique to this frame, and yet others migh invoke
actions that are available from many different contexts.

A convenient organization of the simulator program is to write  a separate
PILOT program module for each frame to be displayed and it's associated
control code.  Each file would also contain the necessary code to accept
keyboard input and perform the appropriate actions such as link to other
frames.

An alternate approach is to build each frame as a separate file without the
control code.  Thus, you would have a set of files that contain only the text
to be displayed and the control code in another file.

The second approach may be more efficient in the use of space because of the
reduction of duplicate routines.  Yet, if space is not a concern, you will
find it much easier to use the first approach where debugging and controlling
your program become less of a task.

In either approach, a careful study and understanding of the machine to be
simulated is required.  For each frame, you should also be able to simulate
incorrect actions as well as correct actions.  Make note of the real
machine's messages and displayed actions for every possible operator command.
An action taken on one frame may effect the information displayed on another
frame.  The frame text that can be changed or effected by student commands
will have to be represent by variables called frame variables.

Frame variables will have to be set to an initial value in your entry module.
This gives you the ability to set the initial status or condition of the
machine to be simulated.  It also allows you to break apart specific tasks
you would like to have the student accomplish.

Development Tasks

The following sequence of tasks may be helpful in building your machine
simulator:

Study the operation of the target machine.  Make note of incorrect actions as
well as correct actions.

Determine the machine frames to be simulated.  Create a separate text file
(nnnn.PIL) for each frame to be displayed.  In the text file type an exact
copy of the frame display screen.  In naming your frame files, choose names
which aid in the identification of the associated frames.  After you have
created the text file, insert PILOT's (T:) command to type the text to the
screen.  Most machine frames will have an area designated as the command line
where the blinking cursor is located awaiting response.  This can be
accomplished using the (TS:gx,y) command.  Use the ACCEPT (A:) command to
wait for a response to be evaluated.

Determine the machine commands that cause one frame to link to other frames.
In some cases, an INDEX key on the console may have to be simulated by use of
the ALT key.  Some frames may not link to other frames directly, yet have to
go to a menu or index frame first.  Using PILOT's SYSX routine may be of
benefit here.  In either case, MATCH statements or use of the function keys
should direct the program to a LINK command (L:) that links the frame to
another.  Once this is accomplished for one frame, much of the same code can
placed in the other frame files.

Determine the frame variables for each frame.  Frame text that is changed or
effected by commands should be identified.  Once identified, you must create
a variable name that represents that text item.  Use caution in selecting
variable names.  Try to chose a name that can be easily associated with the
text or function simulated.  Remember you must first dimension a string
variable before using it.  The variable length is set when you Dimension (D:)
the variable.  Next replace the text items with the appropriate variable
names using ($var$) within the frame text.  Once the initial value of the
variables is set in your entry module, you can change them using the COMPUTE
(C:) command.

Determine other machine commands that require simulation.  First, ensure you
have a list of the commands to be simulated or acted upon from the command
line.  Then create MATCH (M:) statements for each of the possible commands.
Next determine what all should happen if a MATCH would occur.  Frame
variables can be changed by using the Compute on condition Yes statement
(CY:). Other variables may change depending on contents of other variables.
For example, you may need a way to change a variable only if it's content had
a particular string value. CY(var1$="content"):var$="new content"

Determine error messages, not simulated commands and simulator messages to be
used.  Although the goal is to provide a real as possible environment, it may
not be practical to simulate every possible command or response.  In those
cases, the author may want to provide error handling routines that provide a
" Message from the Simulator" to be displayed on a predetermined area of the
screen.  For example, a message might be "Message from Simulator -- Command
not known or not simulated "  or "Simulated at greater than normal speed."

Test the simulator next to the real machine.  This will allow you to see many
things that you may not have noticed before.  Next, ensure your entry modules
are task oriented.  You can provide a workbook that directs the student to
try certain tasks and asks them what has changed or taken place.

Sample Machine Simulator Program

The SAMPLE12.PIL, and SAMPLE13.PIL files contains an example of a machine
simulator that presents an Operator control frame similar to those on many
IBM systems. Try it to see a section of a simulator in action.


Appendix F. CALLING EXTERNAL PROGRAMS

Using the EXEC facility, a PILOT program can execute another program or DOS
command. EXEC permits the program to execute any command line, as if it were
entered to the DOS command line prompt. The command could perform DOS
functions such as DIR or COPY. It could as easily execute a program written
in BASIC or PASCAL, or execute another program product such as a word
processor or spread sheet. The called program need not be written in any
special manner, it is executed in an environment which is the same as if it
were executed via a DOS command line. When the called program terminates,
control is returned to the PILOT program which resumes execution at the next
statement.

To use the EXEC facility the file EXEC.BIN must be present. The GETFILE.PIM
macro must be used to load and initialize the EXEC.BIN file. Once this is
done any number of calls to EXEC may be performed via the V: statement.

To use EXEC in a program follow these steps:

     Use the EZ editor to expand the GETFILE.PIM macro
     in the initial portion of the PILOT program.
     GETFILE.PIM prompts for a file name, enter the name
     EXEC.BIN. It also prompts for a string name, use
     the name EXEC$.

     At any point within the PILOT program use the following
     statements to call an external program:

          C:EXEC$(9,80) = "any DOS command line here"
          V:EXEC$

The string passed to EXEC$ may be any command line, exactly as it would be
typed to the DOS command prompt "A>". For example, the following lines
perform a directory command.

     C:EXEC$(9,80) = "DIR"
     V:EXEC$

The following lines call a BASIC program named "HELLO".

     C:EXEC$(9,80) = "BASIC HELLO"
     V:EXEC$

If the command does not execute as expected, then upon return from the V:
statement, the following line would display an error code per the DOS Error
Return Table found in a DOS manual appendix.

     T:Return code is #(ASC(EXEC$(3)))

As an additional return, EXEC$ returns the drive letter in which the file
COMMAND.COM was found in string position EXEC$(4). This information might be
useful in determining whether a program is executing from floppy or fixed
disk.


Appendix G. SUPPLEMENTAL MATERIALS

This section describes various other printed and program materials that may
be useful in PILOT program authoring.

ADCIS

The "Association for the Development of Computer-Based Instructional Systems"
has a PILOT Language Special Interest Group. This association holds annual
meetings and publishes newsletters and the "Journal of Computer-Based
Instruction". ADCIS national offices can be reached at [phone].

WCS

Washington Computer Services, the developer of PILOT, publishes several
products and services for PILOT users:

UPDATE SERVICE - New releases of PILOT are supplied.

ADVANCED FEATURE LIBRARY - A package of utilities, special device drivers and
useful subroutines to increase productivity for the PILOT programmer.

LEARNPI and DESIGNER - A 3-diskette tutorial set, LEARNPI, written in PILOT
on PILOT written by George Gerhold and Robert Urso. It covers basic
programming and screen design topics.

VIDEO SCRIPT EXECUTIVE - VSX is an authoring environment for presentations
and lessons which may include video, text, graphics, mouse, touch screen and
video. VSX can reduce program development time by isolating the author from
programming details. The user can extend the power of VSX by coding in PILOT
as necessary.

For complete information contact Washington Computer Services directly.
Phone: [phone].

SRA

SRA publishes beginner's level self-study course (book and diskette) entitled
"Developing Computer-Based Training with PC/PILOT" by Kirk Richardson and
Valerie Mock.

ASYS

ASYS publishes PROPI a complete authoring system which can be used with the
PILOT language to provide a comprehensive large-scale authoring environment.
ASYS phone:  [phone].